1. Field of the Invention
The invention relates to dynamic frame processing and, more particularly, to a computer-implemented method for automatically generating dynamic frame packing groups for an automation system, a device for automatically generating dynamic frame packing groups for an automation system and a computer program product.
2. Description of the Related Art
In order to increase the transmission rate of data from field devices to controllers in automation systems, the concept of dynamic frame packing (DFP) was introduced, whereby a data transmission is effected using container frames. Here, terminals that are assigned to a packing group transmit their data inside a container frame. The advantage of this is that the overhead for Ethernet frames that are used is borne only once for a given transmission, because of the container frame only a preamble, a start frame delimiter and a header are used, for example. This enables the packing density to be increased, so that within one clock cycle a data transmission by a plurality of field devices can occur, the transmission refreshment rates being significantly increased in comparison with a data transmission that does not use DFP.
FIG. 1 shows the structure of a typical realtime frame, this frame itself being encapsulated for Ethernet transmissions in accordance with Request for Comment (RFC) 894 using the elements destination address, source address, Ether type and Cyclic Redundancy Check (CRC). Where priority tagging is used in accordance with Institute of Electrical and Electronic Engineers (IEEE) Standard 802.1Q with the Ether type set to 0x8100, followed by a priority/VLAN field, followed by a second Ether type that is set to 0x8892 and that displays a realtime frame.
The frame ID is used to identify the frame itself, where C_SDU is designated for transporting the contents of the IO data and APDU status specifies the status of the frame.
The C_SDU can be structured so that it either carries the IO data of an individual field device or else it carries the IO data of several field devices. In the latter case, a part of the C_SDU (called the “subframe”) carries the IO data of a particular field device, in which case the frame is subdivided into several subframes.
The reason for that is using a subdivision into frames is to minimize the bandwidth that is required and to consistently optimize the performance. As shown in FIG. 1, the overhead of a frame, i.e., the bytes to be transported besides the C_SDU, is 28 bytes. However, since the InterframeGap is an additional 12 bytes, the preamble is 7 bytes and the start frame delimiter is 1 byte and these must additionally be taken into account, the total overhead of a frame amounts to 48 bytes (or 42 bytes if the preamble is shortened to 1 byte). If the C_SDU is additionally smaller than 40 bytes, the difference must additionally be added.
Thus, it is apparent that using subdivided frames reduces the bandwidth required by combining subframes 110 and 112 because, as shown in FIG. 2, the overhead of a subframe is only 6 bytes. By combining several subframes in a single frame, the overhead for the frame that is used is thus only incurred once.
Each of the subframes 110 and 112 is assigned a position, a control bit, a data length that describes the length of the C_SDU, a cycle counter, a data status and a CRC. Here, the position is a unique identifier for a given subframe, where the list of subframes is concluded by a special subframe with the position number 0.
The control bit is used to specify whether the CRC and cycle counter of the subframe should be ignored.
The data status of a subframe specifies the data status of the subframe. The data status within the APDU status of the frame specifies the data status of the frame. If the frame consists of subframes, the data status of the frame can be ignored. Furthermore, it is helpful to assign the data status of the frame to a static value.